fix shared variant ordering bug#718
Conversation
…ils-if-it-was-parsed-with-rapidjson-on-server-side
|
@codex[agent] can you review this PR according to the guide in .agents/review.md |
Findings: no issues spotted. Sorting SharedVariant into the variant list before reading discriminators matches the server’s sorted ordering, and the new JSON/Dynamic cases exercise both clients via param_client. Open: I did not rerun the suite locally; relying on the added coverage and existing CI. |
|
@claude[agent] can you review this PR according to the guide in .agents/review.md |
Review of PR #[Fix shared variant ordering bug]I've reviewed this PR according to FindingsNo material issues found. The PR correctly addresses the root cause. Code AnalysisCore fix (dynamic.py:224): The one-line sort is correct. I verified against the ClickHouse server source:
Sync/async parity: ✓ No issue. The fix is in Tests: ✓ Well-covered
CHANGELOG: ✓ Entry is clear, accurate, and follows repo style. Explains the problem and the fix at the right level of detail. Public API: ✓ No changes to public surface. This is pure read-path correctness. Compatibility: ✓ No compatibility concerns. This is a bug fix that restores correct behavior for types sorting after "SharedVariant" alphabetically (UInt*, Tuple, UUID, etc.). There is no backward compatibility to preserve here, the old behavior was wrong. Minor Observations
The PR is ready to merge. |
Summary
ClickHouse's
DataTypeVariantconstructor sorts its members alphabetically by name, and the wire-format discriminator byte indexes into that sorted order. The client was appendingSharedVariantto the end of the variant list without sorting, so any Dynamic/JSON path whose type name sorted after"SharedVariant"(e.g.UInt*,Tuple(...),UUID) was decoded through the wrong variant reader.The fix is one line in
read_dynamic_prefixwhere we sortvariant_typesby name after appendingSharedVariant.Closes #712.
Checklist
Delete items not relevant to your PR: